『A Philosophy of Software Design』
https://gyazo.com/05c6cdbf4119afdccbc9f08388e542be
2018/4/6
2021/7に第2版が出た
差分はChapter21が増えたのと、いくつかの章への追記
著者が翻訳を出さないことを明言してるらしい
英語はだいぶ平易なので読める
102の最後の方で、著者は出身が低レイヤ寄りなのでその辺も考慮しながら読むと良いみたいなことを言ってた
第2版のものも追加した
200ページぐらいしか無いのねmrsekut.icon
Preface
最も基本的な問題は問題の分解だが、大学で教えられないがち
なので著者がそういうクラスを作った(CS190)
この本はクラスから生まれた設計原則に基づいている
1 Introduction
複雑さと戦うための2つのアプローチ
コードをシンプルで明白にして複雑さを排除する
カプセル化する
2 The Nature of Complexity
3 Working Code Isn't Enough
著者と思想が似ているため、あまり衝撃を受けるほどの感動がないmrsekut.icon
そうだね、わかるわかる、という気持ちになる
4 Modules Should Be Deep
5 Information Hiding (and Leakage)
6 General-Purpose Modules are Deeper
特殊ケースではなく汎用ケースに対応するように書く
具体的なケースは、汎用的なものと分離して、上方や下方に押し上げる
上方の例は、一部のレイヤでしかIOを使わない感じ
下方の例は、各OSへの特殊対応を抽象化してる感じ
7 Different Layer, Different Abstraction
8 Pull Complexity Downwards
複雑性をモジュール内に閉じ込めて、
利用者が使いやすいインターフェースを公開しよう
逆に、無駄に細かい挙動の設定をインターフェースにわざわざ露出させるな、
といった至極当たり前のことが解説されている
9 Better Together Or Better Apart?
細かく分けるのもいくらかの問題があるよという主張
あまり見かけない割と珍しい主張
と、思ったが、moduleぐらいの抽象度で考えれば納得感はあるmrsekut.icon
概念的に同じ、一緒に使う、にも関わらず別のmoduleにあると、ん？となる
そんなにアクロバットな主張をしてるわけでもない
細かく分けるより一緒にしたほうがシンプルになる場合はそっちを選ぶのがええよ、と言ってるだけ
10 Define Errors Out Of Existence
11 Design it Twice
割と好きmrsekut.icon
12 Why Write Comments? The Four Excuses
コメントを書こうねという話
コメントを書かない以下のような意見に対する批判
「良いコードは自己文書化する。」
「コメントを書く時間がない。」
「コメントは古くなり、誤解を招くようになる。」
「私が見たコメントはすべて価値がない。何のために書くのか？」
13 Comments Should Describe Things that Aren't Obvious from the Code
良いコメントの書き方について
分量多すぎてちょっと読み飛ばしちゃったが、主張は割とわかるmrsekut.icon
要は、コメントにも抽象度が存在して、
詳細を知るための実装コメント
のように分類して考えるというもの
14 Choosing Names
命名について
正確さと一貫性
15 Write The Comments First
タイトルの通り
命名や型を先に考えるのとほぼ同じ
16 Modifying Existing Code
17 Consistency
自分のアプローチよりも既存のコードのアプローチを採用するか否かとかの話
18 Code Should be Obvious
割と強めの主張に見えたが、自分が慣れているだけで、インターフェースの観点から見れば確かにそうかもという気持ちになったmrsekut.icon
event駆動はトレースしづらい
tupleは値に対する情報量がない
19 Software Trends
OOPの2つの継承
アジャイル
ユニットテスト
TDD
デザパタ
getter/setter
20 Designing for Performance
パフォーマンス
21 Decide What Matters
第2版で増えた章
いいねmrsekut.icon
22 Conclusion